-
Notifications
You must be signed in to change notification settings - Fork 542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting up ESLint #110
Setting up ESLint #110
Conversation
Codecov Report
@@ Coverage Diff @@
## master #110 +/- ##
==========================================
- Coverage 94.52% 94.06% -0.46%
==========================================
Files 62 74 +12
Lines 3522 3536 +14
Branches 372 374 +2
==========================================
- Hits 3329 3326 -3
- Misses 193 210 +17
|
I think the lint check should install ESLint modules (parser, plugins, etc.) instead of TSLint. |
I would look at the github action in the core repo. It may help you get this figured out, and it would be easier to maintain if both repos used the same mechanism. |
@rezakrimi can you please make sure the build actually passes ? |
I'm planning to update the lint checks over the weekend. However, some of the files have linting issues that are not fixable by the linter, so the check will still fail. How are we going to work around that? Do you think that fixing lint issues should be a separate issue or should it be part of this PR? |
Fixing lint issues should be a part of this PR if it is not too many errors. If it is a large number of errors it may be done in a follow up, but the follow up should be done quickly. |
Should I make a new PR to trigger github actions? |
"header" | ||
], | ||
extends: [ | ||
"./node_modules/gts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could extend the eslint config from the main repo so that changes are automatically picked up after a main repo release? wdyt @dyladan? (Not in scope for this PR though!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there is a way to depend on the file directly in github instead of a release. Very interesting idea though. A package like @opentelemetry/eslint-config
would be a welcome addition I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we could do something like npm install --save-dev https://github.com/opentelemetry-js/opentelemetry-js/tarball/master
, or just the normal cloning url
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dyladan maybe we can create some general package that can be easily shared between contrib repo and here andd maybe even a 3rd party contrib. We could put there a bit more stuff, eslint, karma config, etc. basically all things that could be shared. WDYT ?
As mentioned here: "When you create a pull request from a forked repository to the base repository, GitHub sends the |
Here is a list of all the linting issues that are not fixable by the linter. Please have a look and comment on how these should be resolved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@OlivierAlbertini Since you're the author of the DNS plugin, could you please help on resolving the issue mentioned here for that plugin? |
@rezakrimi can you update the doc to make it clear which issues you have resolved and which you have not? |
I did, it's on the header for each package |
message: error!.message, | ||
}, | ||
}); | ||
if (semver.lt(process.versions.node, '9.0.0')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created a new dns lookup method in this file that is compatible with node 8. The only thing is that the node INVALID_ARGUMENT
code seemed to be different in node 8 so I had to make separate cases for this test. If this is fine then I'll open this PR to be merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea why the canonical code is different between them? I would rather have behavior consistent across versions if possible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
based on this it seems like it's possible to have different error codes in different major releases. The error message was the same though.
Which problem is this PR solving?
Short description of the changes
- None of the files are modified by the linter to keep the PR small